Autogenerated HTML docs for v1.5.6.1-156-ge903b
diff --git a/user-manual.html b/user-manual.html index 0116b84..3c8d094 100644 --- a/user-manual.html +++ b/user-manual.html
@@ -1,12 +1,12 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#id280264">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX +<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git-fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git-pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git-fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#id280263">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git.</p><p><a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a> and <a href="#exploring-git-history" title="Chapter 2. Exploring git history">Chapter 2, <i>Exploring git history</i></a> explain how to fetch and study a project using git—read these chapters to learn how to build and test a particular version of a software project, search for regressions, and so on.</p><p>People needing to do actual development will also want to read <a href="#Developing-with-git" title="Chapter 3. Developing with git">Chapter 3, <i>Developing with git</i></a> and <a href="#sharing-development" title="Chapter 4. Sharing development with others">Chapter 4, <i>Sharing development with others</i></a>.</p><p>Further chapters cover more specialized topics.</p><p>Comprehensive reference documentation is available through the man -pages. For a command such as "git clone", just use</p><div class="literallayout"><p>$ man git-clone</p></div><p>See also <a href="#git-quick-start" title="Appendix A. Git Quick Reference">Appendix A, <i>Git Quick Reference</i></a> for a brief overview of git commands, +pages. For a command such as "git clone <repo>", just use</p><div class="literallayout"><p>$ man git-clone</p></div><p>See also <a href="#git-quick-start" title="Appendix A. Git Quick Reference">Appendix A, <i>Git Quick Reference</i></a> for a brief overview of git commands, without any explanation.</p><p>Finally, see <a href="#todo" title="Appendix B. Notes and todo list for this manual">Appendix B, <i>Notes and todo list for this manual</i></a> for ways that you can help make this manual more -complete.</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="repositories-and-branches"></a>Chapter 1. Repositories and Branches</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-get-a-git-repository"></a>How to get a git repository</h2></div></div></div><p>It will be useful to have a git repository to experiment with as you +complete.</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="repositories-and-branches"></a>Chapter 1. Repositories and Branches</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git-fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-get-a-git-repository"></a>How to get a git repository</h2></div></div></div><p>It will be useful to have a git repository to experiment with as you read this manual.</p><p>The best way to get one is by using the <a href="git-clone.html" target="_top">git-clone(1)</a> command to download a copy of an existing repository. If you don't already have a project in mind, here are some interesting examples:</p><div class="literallayout"><p> # git itself (approx. 10MB download):<br> @@ -77,7 +77,7 @@ <br> if (mkdir(".git", 0755) < 0) {</p></div><p>As you can see, a commit shows who made the latest change, what they did, and why.</p><p>Every commit has a 40-hexdigit id, sometimes called the "object name" or the -"SHA1 id", shown on the first line of the "git show" output. You can usually +"SHA1 id", shown on the first line of the "git-show" output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this longer name can also be useful. Most importantly, it is a globally unique name for this commit: so if you tell somebody else the object name (for @@ -202,7 +202,7 @@ is usually a shortcut for the HEAD branch in the repository "origin".</p><p>For the complete list of paths which git checks for references, and the order it uses to decide which to choose when there are multiple references with the same shorthand name, see the "SPECIFYING -REVISIONS" section of <a href="git-rev-parse.html" target="_top">git-rev-parse(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Updating-a-repository-with-git-fetch"></a>Updating a repository with git fetch</h2></div></div></div><p>Eventually the developer cloned from will do additional work in her +REVISIONS" section of <a href="git-rev-parse.html" target="_top">git-rev-parse(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Updating-a-repository-with-git-fetch"></a>Updating a repository with git-fetch</h2></div></div></div><p>Eventually the developer cloned from will do additional work in her repository, creating new commits and advancing the branches to point at the new commits.</p><p>The command "git fetch", with no arguments, will update all of the remote-tracking branches to the latest version found in her @@ -212,7 +212,7 @@ $ git fetch linux-nfs<br> * refs/remotes/linux-nfs/master: storing branch 'master' ...<br> commit: bf81b46</p></div><p>New remote-tracking branches will be stored under the shorthand name -that you gave "git remote add", in this case linux-nfs:</p><div class="literallayout"><p>$ git branch -r<br> +that you gave "git-remote add", in this case linux-nfs:</p><div class="literallayout"><p>$ git branch -r<br> linux-nfs/master<br> origin/master</p></div><p>If you run "git fetch <remote>" later, the tracking branches for the named <remote> will be updated.</p><p>If you examine the file .git/config, you will see that git has added @@ -417,7 +417,7 @@ that of the HEAD. The command "git diff —cached", which shows the difference between the HEAD and the index, should therefore produce no output at that point.</p><p>Modifying the index is easy:</p><p>To update the index with the new contents of a modified file, use</p><div class="literallayout"><p>$ git add path/to/file</p></div><p>To add the contents of a new file to the index, use</p><div class="literallayout"><p>$ git add path/to/file</p></div><p>To remove a file from the index and from the working tree,</p><div class="literallayout"><p>$ git rm path/to/file</p></div><p>After each step you can verify that</p><div class="literallayout"><p>$ git diff --cached</p></div><p>always shows the difference between the HEAD and the index file—this -is what you'd commit if you created the commit now—and that</p><div class="literallayout"><p>$ git diff</p></div><p>shows the difference between the working tree and the index file.</p><p>Note that "git add" always adds just the current contents of a file +is what you'd commit if you created the commit now—and that</p><div class="literallayout"><p>$ git diff</p></div><p>shows the difference between the working tree and the index file.</p><p>Note that "git-add" always adds just the current contents of a file to the index; further changes to the same file will be ignored unless you run git-add on the file again.</p><p>When you're ready, just run</p><div class="literallayout"><p>$ git commit</p></div><p>and git will prompt you for a commit message and then create the new commit. Check to make sure it looks like what you expected with</p><div class="literallayout"><p>$ git show</p></div><p>As a special shortcut,</p><div class="literallayout"><p>$ git commit -a</p></div><p>will update the index with any files that you've modified or removed @@ -440,7 +440,7 @@ body.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ignoring-files"></a>Ignoring files</h2></div></div></div><p>A project will often generate files that you do <span class="emphasis"><em>not</em></span> want to track with git. This typically includes files generated by a build process or temporary backup files made by your editor. Of course, <span class="emphasis"><em>not</em></span> tracking files with git -is just a matter of <span class="emphasis"><em>not</em></span> calling "<code class="literal">git add</code>" on them. But it quickly becomes +is just a matter of <span class="emphasis"><em>not</em></span> calling "<code class="literal">git-add</code>" on them. But it quickly becomes annoying to have these untracked files lying around; e.g. they make "<code class="literal">git add .</code>" and "<code class="literal">git commit -a</code>" practically useless, and they keep showing up in the output of "<code class="literal">git status</code>".</p><p>You can tell git to ignore certain files by creating a file called .gitignore @@ -582,7 +582,7 @@ this is an advanced topic to be left for <a href="#cleaning-up-history" title="Chapter 5. Rewriting history and maintaining patch series">another chapter</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="checkout-of-path"></a>Checking out an old version of a file</h3></div></div></div><p>In the process of undoing a previous bad change, you may find it useful to check out an older version of a particular file using -<a href="git-checkout.html" target="_top">git-checkout(1)</a>. We've used git checkout before to switch +<a href="git-checkout.html" target="_top">git-checkout(1)</a>. We've used git-checkout before to switch branches, but it has quite different behavior if it is given a path name: the command</p><div class="literallayout"><p>$ git checkout HEAD^ path/to/file</p></div><p>replaces path/to/file by the contents it had in the commit HEAD^, and also updates the index to match. It does not change branches.</p><p>If you just want to look at an old version of the file, without @@ -648,9 +648,9 @@ "tip of the line" as being dangling, but there might be a whole deep and complex commit history that was dropped.)</p><p>If you decide you want the history back, you can always create a new reference pointing to it, for example, a new branch:</p><div class="literallayout"><p>$ git branch recovered-branch 7281251ddd</p></div><p>Other types of dangling objects (blobs and trees) are also possible, and -dangling objects can arise in other situations.</p></div></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="sharing-development"></a>Chapter 4. Sharing development with others</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="getting-updates-with-git-pull"></a>Getting updates with git pull</h2></div></div></div><p>After you clone a repository and make a few changes of your own, you +dangling objects can arise in other situations.</p></div></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="sharing-development"></a>Chapter 4. Sharing development with others</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git-pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="getting-updates-with-git-pull"></a>Getting updates with git-pull</h2></div></div></div><p>After you clone a repository and make a few changes of your own, you may wish to check the original repository for updates and merge them -into your own work.</p><p>We have already seen <a href="#Updating-a-repository-with-git-fetch" title="Updating a repository with git fetch">how to keep remote tracking branches up to date</a> with <a href="git-fetch.html" target="_top">git-fetch(1)</a>, +into your own work.</p><p>We have already seen <a href="#Updating-a-repository-with-git-fetch" title="Updating a repository with git-fetch">how to keep remote tracking branches up to date</a> with <a href="git-fetch.html" target="_top">git-fetch(1)</a>, and how to merge two branches. So you can merge in changes from the original repository's master branch with:</p><div class="literallayout"><p>$ git fetch<br> $ git merge origin/master</p></div><p>However, the <a href="git-pull.html" target="_top">git-pull(1)</a> command provides a way to do this in @@ -686,7 +686,7 @@ the original mailbox, with authorship and commit log message each taken from the message containing each patch.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="public-repositories"></a>Public git repositories</h2></div></div></div><p>Another way to submit changes to a project is to tell the maintainer of that project to pull the changes from your repository using -<a href="git-pull.html" target="_top">git-pull(1)</a>. In the section "<a href="#getting-updates-with-git-pull" title="Getting updates with git pull">Getting updates with git pull</a>" we described this as a way to get +<a href="git-pull.html" target="_top">git-pull(1)</a>. In the section "<a href="#getting-updates-with-git-pull" title="Getting updates with git-pull">Getting updates with git-pull</a>" we described this as a way to get updates from the "main" repository, but it works just as well in the other direction.</p><p>If you and the maintainer both have accounts on the same machine, then you can just pull changes from each other's repositories directly; @@ -732,8 +732,7 @@ $ cd proj.git<br> $ git --bare update-server-info<br> $ chmod a+x hooks/post-update</p></div><p>(For an explanation of the last two lines, see -<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a>, and the documentation -<a href="githooks.html" target="_top">githooks(5)</a>[Hooks used by git].)</p><p>Advertise the URL of proj.git. Anybody else should then be able to +<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a> and <a href="githooks.html" target="_top">githooks(5)</a>.)</p><p>Advertise the URL of proj.git. Anybody else should then be able to clone or pull from that URL, for example with a command line like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also <a href="howto/setup-git-server-over-http.txt" target="_top">setup-git-server-over-http</a> for a slightly more sophisticated setup using WebDAV which also @@ -779,10 +778,10 @@ solution is to retry the push after first updating your work by either a pull or a fetch followed by a rebase; see the <a href="#setting-up-a-shared-repository" title="Setting up a shared repository">next section</a> and -<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a>[git for CVS users] for more.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="setting-up-a-shared-repository"></a>Setting up a shared repository</h3></div></div></div><p>Another way to collaborate is by using a model similar to that +<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a> for more.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="setting-up-a-shared-repository"></a>Setting up a shared repository</h3></div></div></div><p>Another way to collaborate is by using a model similar to that commonly used in CVS, where several developers with special rights all push to and pull from a single shared repository. See -<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a>[git for CVS users] for instructions on how to +<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a> for instructions on how to set this up.</p><p>However, while there is nothing wrong with git's support for shared repositories, this mode of operation is not generally recommended, simply because the mode of collaboration that git supports—by @@ -1093,7 +1092,7 @@ and understanding why Y* was broken would probably be easier.</p><p>Partly for this reason, many experienced git users, even when working on an otherwise merge-heavy project, keep the history linear by rebasing against the latest upstream version before -publishing.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="advanced-branch-management"></a>Chapter 6. Advanced branch management</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="fetching-individual-branches"></a>Fetching individual branches</h2></div></div></div><p>Instead of using <a href="git-remote.html" target="_top">git-remote(1)</a>, you can also choose just +publishing.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="advanced-branch-management"></a>Chapter 6. Advanced branch management</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git-fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="fetching-individual-branches"></a>Fetching individual branches</h2></div></div></div><p>Instead of using <a href="git-remote.html" target="_top">git-remote(1)</a>, you can also choose just to update one branch at a time, and to store it locally under an arbitrary name:</p><div class="literallayout"><p>$ git fetch origin todo:my-todo-work</p></div><p>The first argument, "origin", just tells git to fetch from the repository you originally cloned from. The second argument tells git @@ -1117,7 +1116,7 @@ described in the following section. However, note that in the situation above this may mean losing the commits labeled "a" and "b", unless you've already created a reference of your own pointing to -them.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="forcing-fetch"></a>Forcing git fetch to do non-fast-forward updates</h2></div></div></div><p>If git fetch fails because the new head of a branch is not a +them.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="forcing-fetch"></a>Forcing git-fetch to do non-fast-forward updates</h2></div></div></div><p>If git fetch fails because the new head of a branch is not a descendant of the old head, you may force the update with:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git +master:refs/remotes/example/master</p></div><p>Note the addition of the "+" sign. Alternatively, you can use the "-f" flag to force updates of all the fetched branches, as in:</p><div class="literallayout"><p>$ git fetch -f origin</p></div><p>Be aware that commits that the old version of example/master pointed at may be lost, as we saw in the previous section.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="remote-branch-configuration"></a>Configuring remote branches</h2></div></div></div><p>We saw above that "origin" is just a shortcut to refer to the @@ -1135,7 +1134,7 @@ after</p><div class="literallayout"><p>$ git config remote.example.url git://example.com/proj.git</p></div><p>then the following two commands will do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:refs/remotes/example/master<br> $ git fetch example master:refs/remotes/example/master</p></div><p>Even better, if you add one more option:</p><div class="literallayout"><p>$ git config remote.example.fetch master:refs/remotes/example/master</p></div><p>then the following commands will all do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:refs/remotes/example/master<br> $ git fetch example master:refs/remotes/example/master<br> -$ git fetch example</p></div><p>You can also add a "+" to force the update each time:</p><div class="literallayout"><p>$ git config remote.example.fetch +master:ref/remotes/example/master</p></div><p>Don't do this unless you're sure you won't mind "git fetch" possibly +$ git fetch example</p></div><p>You can also add a "+" to force the update each time:</p><div class="literallayout"><p>$ git config remote.example.fetch +master:ref/remotes/example/master</p></div><p>Don't do this unless you're sure you won't mind "git-fetch" possibly throwing away commits on mybranch.</p><p>Also note that all of the above configuration can be performed by directly editing the file .git/config instead of using <a href="git-config.html" target="_top">git-config(1)</a>.</p><p>See <a href="git-config.html" target="_top">git-config(1)</a> for more details on the configuration @@ -1362,7 +1361,7 @@ in case you corrupt things even more in the process.</p><p>We'll assume that the problem is a single missing or corrupted blob, which is sometimes a solvable problem. (Recovering missing trees and especially commits is <span class="strong"><strong>much</strong></span> harder).</p><p>Before starting, verify that there is corruption, and figure out where -it is with <a href="git-fsck.html" target="_top">git-fsck(1)</a>; this may be time-consuming.</p><p>Assume the output looks like this:</p><div class="literallayout"><p>$ git-fsck --full<br> +it is with <a href="git-fsck.html" target="_top">git-fsck(1)</a>; this may be time-consuming.</p><p>Assume the output looks like this:</p><div class="literallayout"><p>$ git fsck --full<br> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8<br> to blob 4b9458b3786228369c63936db65827de3cc06200<br> missing blob 4b9458b3786228369c63936db65827de3cc06200</p></div><p>(Typically there will be some "dangling object" messages too, but they @@ -1441,7 +1440,7 @@ number, and will take on values other than 0 for files with merge conflicts.</p></li></ol></div><p>The index is thus a sort of temporary staging area, which is filled with a tree which you are in the process of working on.</p><p>If you blow the index away entirely, you generally haven't lost any -information as long as you have the name of the tree that it described.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="submodules"></a>Chapter 8. Submodules</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id280264">Pitfalls with submodules</a></span></dt></dl></div><p>Large projects are often composed of smaller, self-contained modules. For +information as long as you have the name of the tree that it described.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="submodules"></a>Chapter 8. Submodules</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id280263">Pitfalls with submodules</a></span></dt></dl></div><p>Large projects are often composed of smaller, self-contained modules. For example, an embedded Linux distribution's source tree would include every piece of software in the distribution with some local modifications; a movie player might need to build against a specific, known-working version of a @@ -1487,8 +1486,8 @@ $ for i in a b c d<br> do<br> git submodule add ~/git/$i<br> -done</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Do not use local URLs here if you plan to publish your superproject!</p></div><p>See what files <code class="literal">git submodule</code> created:</p><div class="literallayout"><p>$ ls -a<br> -. .. .git .gitmodules a b c d</p></div><p>The <code class="literal">git submodule add</code> command does a couple of things:</p><div class="itemizedlist"><ul type="disc"><li> +done</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Do not use local URLs here if you plan to publish your superproject!</p></div><p>See what files <code class="literal">git-submodule</code> created:</p><div class="literallayout"><p>$ ls -a<br> +. .. .git .gitmodules a b c d</p></div><p>The <code class="literal">git-submodule add</code> command does a couple of things:</p><div class="itemizedlist"><ul type="disc"><li> It clones the submodule under the current directory and by default checks out the master branch. </li><li> @@ -1508,12 +1507,12 @@ -d96249ff5d57de5de093e6baff9e0aafa5276a74 d</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The commit object names shown above would be different for you, but they should match the HEAD commit object names of your repositories. You can check it by running <code class="literal">git ls-remote ../a</code>.</p></div><p>Pulling down the submodules is a two-step process. First run <code class="literal">git submodule -init</code> to add the submodule repository URLs to <code class="literal">.git/config</code>:</p><div class="literallayout"><p>$ git submodule init</p></div><p>Now use <code class="literal">git submodule update</code> to clone the repositories and check out the +init</code> to add the submodule repository URLs to <code class="literal">.git/config</code>:</p><div class="literallayout"><p>$ git submodule init</p></div><p>Now use <code class="literal">git-submodule update</code> to clone the repositories and check out the commits specified in the superproject:</p><div class="literallayout"><p>$ git submodule update<br> $ cd a<br> $ ls -a<br> -. .. .git a.txt</p></div><p>One major difference between <code class="literal">git submodule update</code> and <code class="literal">git submodule add</code> is -that <code class="literal">git submodule update</code> checks out a specific commit, rather than the tip +. .. .git a.txt</p></div><p>One major difference between <code class="literal">git-submodule update</code> and <code class="literal">git-submodule add</code> is +that <code class="literal">git-submodule update</code> checks out a specific commit, rather than the tip of a branch. It's like checking out a tag: the head is detached, so you're not working on a branch.</p><div class="literallayout"><p>$ git branch<br> * (no branch)<br> @@ -1535,7 +1534,7 @@ $ git add a<br> $ git commit -m "Updated submodule a."<br> $ git push</p></div><p>You have to run <code class="literal">git submodule update</code> after <code class="literal">git pull</code> if you want to update -submodules, too.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id280264"></a>Pitfalls with submodules</h2></div></div></div><p>Always publish the submodule change before publishing the change to the +submodules, too.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id280263"></a>Pitfalls with submodules</h2></div></div></div><p>Always publish the submodule change before publishing the change to the superproject that references it. If you forget to publish the submodule change, others won't be able to clone the repository:</p><div class="literallayout"><p>$ cd ~/git/super/a<br> $ echo i added another line to this file >> a.txt<br> @@ -1602,7 +1601,7 @@ other direction:</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-database-to-index"></a>object database -> index</h3></div></div></div><p>You read a "tree" file from the object database, and use that to populate (and overwrite—don't do this if your index contains any unsaved state that you might want to restore later!) your current -index. Normal operation is just</p><div class="literallayout"><p>$ git-read-tree <sha1 of tree></p></div><p>and your index file will now be equivalent to the tree that you saved +index. Normal operation is just</p><div class="literallayout"><p>$ git read-tree <sha1 of tree></p></div><p>and your index file will now be equivalent to the tree that you saved earlier. However, that is only your <span class="emphasis"><em>index</em></span> file: your working directory contents have not been modified.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="index-to-working-directory"></a>index -> working directory</h3></div></div></div><p>You update your working directory from the index by "checking out" files. This is not a very common operation, since normally you'd just @@ -1611,7 +1610,7 @@ working directory (i.e. <code class="literal">git-update-index</code>).</p><p>However, if you decide to jump to a new version, or check out somebody else's version, or just restore a previous tree, you'd populate your index file with read-tree, and then you need to check out the result -with</p><div class="literallayout"><p>$ git-checkout-index filename</p></div><p>or, if you want to check out all of the index, use <code class="literal">-a</code>.</p><p>NOTE! git-checkout-index normally refuses to overwrite old files, so +with</p><div class="literallayout"><p>$ git checkout-index filename</p></div><p>or, if you want to check out all of the index, use <code class="literal">-a</code>.</p><p>NOTE! git-checkout-index normally refuses to overwrite old files, so if you have an old version of the tree already checked out, you will need to use the "-f" flag (<span class="emphasis"><em>before</em></span> the "-a" flag or the filename) to <span class="emphasis"><em>force</em></span> the checkout.</p><p>Finally, there are a few odds and ends which are not purely moving @@ -1625,7 +1624,7 @@ previous states represented by other commits.</p><p>In other words, while a "tree" represents a particular directory state of a working directory, a "commit" represents that state in "time", and explains how we got there.</p><p>You create a commit object by giving it the tree that describes the -state at the time of the commit, and a list of parents:</p><div class="literallayout"><p>$ git-commit-tree <tree> -p <parent> [-p <parent2> ..]</p></div><p>and then giving the reason for the commit on stdin (either through +state at the time of the commit, and a list of parents:</p><div class="literallayout"><p>$ git commit-tree <tree> -p <parent> [-p <parent2> ..]</p></div><p>and then giving the reason for the commit on stdin (either through redirection from a pipe or file, or by just typing it at the tty).</p><p>git-commit-tree will return the name of the object that represents that commit, and you should save it away for later use. Normally, you'd commit a new <code class="literal">HEAD</code> state, and while git doesn't care where you @@ -1667,14 +1666,14 @@ </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="examining-the-data"></a>Examining the data</h2></div></div></div><p>You can examine the data represented in the object database and the index with various helper tools. For every object, you can use <a href="git-cat-file.html" target="_top">git-cat-file(1)</a> to examine details about the -object:</p><div class="literallayout"><p>$ git-cat-file -t <objectname></p></div><p>shows the type of the object, and once you have the type (which is -usually implicit in where you find the object), you can use</p><div class="literallayout"><p>$ git-cat-file blob|tree|commit|tag <objectname></p></div><p>to show its contents. NOTE! Trees have binary content, and as a result +object:</p><div class="literallayout"><p>$ git cat-file -t <objectname></p></div><p>shows the type of the object, and once you have the type (which is +usually implicit in where you find the object), you can use</p><div class="literallayout"><p>$ git cat-file blob|tree|commit|tag <objectname></p></div><p>to show its contents. NOTE! Trees have binary content, and as a result there is a special helper for showing that content, called <code class="literal">git-ls-tree</code>, which turns the binary content into a more easily readable form.</p><p>It's especially instructive to look at "commit" objects, since those tend to be small and fairly self-explanatory. In particular, if you follow the convention of having the top commit name in <code class="literal">.git/HEAD</code>, -you can do</p><div class="literallayout"><p>$ git-cat-file commit HEAD</p></div><p>to see what the top commit was.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees"></a>Merging multiple trees</h2></div></div></div><p>Git helps you do a three-way merge, which you can expand to n-way by +you can do</p><div class="literallayout"><p>$ git cat-file commit HEAD</p></div><p>to see what the top commit was.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees"></a>Merging multiple trees</h2></div></div></div><p>Git helps you do a three-way merge, which you can expand to n-way by repeating the merge procedure arbitrary times until you finally "commit" the state. The normal situation is that you'd only do one three-way merge (two parents), and commit it, but if you like to, you @@ -1682,28 +1681,28 @@ that you want to merge, use those to find the closest common parent (a third "commit" object), and then use those commit objects to find the state of the directory ("tree" object) at these points.</p><p>To get the "base" for the merge, you first look up the common parent -of two commits with</p><div class="literallayout"><p>$ git-merge-base <commit1> <commit2></p></div><p>which will return you the commit they are both based on. You should +of two commits with</p><div class="literallayout"><p>$ git merge-base <commit1> <commit2></p></div><p>which will return you the commit they are both based on. You should now look up the "tree" objects of those commits, which you can easily -do with (for example)</p><div class="literallayout"><p>$ git-cat-file commit <commitname> | head -1</p></div><p>since the tree object information is always the first line in a commit +do with (for example)</p><div class="literallayout"><p>$ git cat-file commit <commitname> | head -1</p></div><p>since the tree object information is always the first line in a commit object.</p><p>Once you know the three trees you are going to merge (the one "original" tree, aka the common tree, and the two "result" trees, aka the branches you want to merge), you do a "merge" read into the index. This will complain if it has to throw away your old index contents, so you should make sure that you've committed those—in fact you would normally always do a merge against your last commit (which should thus match what -you have in your current index anyway).</p><p>To do the merge, do</p><div class="literallayout"><p>$ git-read-tree -m -u <origtree> <yourtree> <targettree></p></div><p>which will do all trivial merge operations for you directly in the +you have in your current index anyway).</p><p>To do the merge, do</p><div class="literallayout"><p>$ git read-tree -m -u <origtree> <yourtree> <targettree></p></div><p>which will do all trivial merge operations for you directly in the index file, and you can just write the result out with <code class="literal">git-write-tree</code>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees-2"></a>Merging multiple trees, continued</h2></div></div></div><p>Sadly, many merges aren't trivial. If there are files that have been added, moved or removed, or if both branches have modified the same file, you will be left with an index tree that contains "merge entries" in it. Such an index tree can <span class="emphasis"><em>NOT</em></span> be written out to a tree object, and you will have to resolve any such merge clashes using -other tools before you can write out the result.</p><p>You can examine such index state with <code class="literal">git-ls-files —unmerged</code> -command. An example:</p><div class="literallayout"><p>$ git-read-tree -m $orig HEAD $target<br> -$ git-ls-files --unmerged<br> +other tools before you can write out the result.</p><p>You can examine such index state with <code class="literal">git ls-files —unmerged</code> +command. An example:</p><div class="literallayout"><p>$ git read-tree -m $orig HEAD $target<br> +$ git ls-files --unmerged<br> 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c<br> 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c<br> -100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c</p></div><p>Each line of the <code class="literal">git-ls-files —unmerged</code> output begins with +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c</p></div><p>Each line of the <code class="literal">git ls-files —unmerged</code> output begins with the blob mode bits, blob SHA1, <span class="emphasis"><em>stage number</em></span>, and the filename. The <span class="emphasis"><em>stage number</em></span> is git's way to say which tree it came from: stage 1 corresponds to <code class="literal">$orig</code> tree, stage 2 <code class="literal">HEAD</code> @@ -1716,19 +1715,19 @@ <code class="literal">$orig</code> to <code class="literal">HEAD</code> and <code class="literal">$orig</code> to <code class="literal">$target</code> in a different way. You could resolve this by running your favorite 3-way merge program, e.g. <code class="literal">diff3</code>, <code class="literal">merge</code>, or git's own merge-file, on -the blob objects from these three stages yourself, like this:</p><div class="literallayout"><p>$ git-cat-file blob 263414f... >hello.c~1<br> -$ git-cat-file blob 06fa6a2... >hello.c~2<br> -$ git-cat-file blob cc44c73... >hello.c~3<br> +the blob objects from these three stages yourself, like this:</p><div class="literallayout"><p>$ git cat-file blob 263414f... >hello.c~1<br> +$ git cat-file blob 06fa6a2... >hello.c~2<br> +$ git cat-file blob cc44c73... >hello.c~3<br> $ git merge-file hello.c~2 hello.c~1 hello.c~3</p></div><p>This would leave the merge result in <code class="literal">hello.c~2</code> file, along with conflict markers if there are conflicts. After verifying the merge result makes sense, you can tell git what the final merge result for this file is by:</p><div class="literallayout"><p>$ mv -f hello.c~2 hello.c<br> -$ git-update-index hello.c</p></div><p>When a path is in unmerged state, running <code class="literal">git-update-index</code> for +$ git update-index hello.c</p></div><p>When a path is in unmerged state, running <code class="literal">git-update-index</code> for that path tells git to mark the path resolved.</p><p>The above is the description of a git merge at the lowest level, to help you understand what conceptually happens under the hood. In practice, nobody, not even git itself, uses three <code class="literal">git-cat-file</code> for this. There is <code class="literal">git-merge-index</code> program that extracts the -stages to temporary files and calls a "merge" script on it:</p><div class="literallayout"><p>$ git-merge-index git-merge-one-file hello.c</p></div><p>and that is what higher level <code class="literal">git merge -s resolve</code> is implemented with.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="hacking-git"></a>Chapter 10. Hacking git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></div><p>This chapter covers internal details of the git implementation which +stages to temporary files and calls a "merge" script on it:</p><div class="literallayout"><p>$ git merge-index git-merge-one-file hello.c</p></div><p>and that is what higher level <code class="literal">git-merge -s resolve</code> is implemented with.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="hacking-git"></a>Chapter 10. Hacking git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></div><p>This chapter covers internal details of the git implementation which probably only git developers need to understand.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="object-details"></a>Object storage format</h2></div></div></div><p>All objects have a statically determined "type" which identifies the format of the object (i.e. how it is used, and how it can refer to other objects). There are currently four different object types: "blob", @@ -1790,7 +1789,7 @@ <code class="literal">prepare_revision_walk()</code> for initialization, and then you can get the commits one by one with the function <code class="literal">get_revision()</code>.</p><p>If you are interested in more details of the revision walking process, just have a look at the first implementation of <code class="literal">cmd_log()</code>; call -<code class="literal">git-show v1.3.0~155^2~4</code> and scroll down to that function (note that you +<code class="literal">git show v1.3.0~155^2~4</code> and scroll down to that function (note that you no longer need to call <code class="literal">setup_pager()</code> directly).</p><p>Nowadays, <code class="literal">git log</code> is a builtin, which means that it is _contained_ in the command <code class="literal">git</code>. The source side of a builtin is</p><div class="itemizedlist"><ul type="disc"><li> a function called <code class="literal">cmd_<bla></code>, typically defined in <code class="literal">builtin-<bla>.c</code>, @@ -1839,8 +1838,8 @@ works, find the source code for it (something like <code class="literal">git grep read_object_with | grep ":[a-z]"</code> in the git repository), and read the source.</p><p>To find out how the result can be used, just read on in <code class="literal">cmd_cat_file()</code>:</p><div class="literallayout"><p> write_or_die(1, buf, size);</p></div><p>Sometimes, you do not know where to look for a feature. In many such cases, -it helps to search through the output of <code class="literal">git log</code>, and then <code class="literal">git show</code> the -corresponding commit.</p><p>Example: If you know that there was some test case for <code class="literal">git bundle</code>, but +it helps to search through the output of <code class="literal">git log</code>, and then <code class="literal">git-show</code> the +corresponding commit.</p><p>Example: If you know that there was some test case for <code class="literal">git-bundle</code>, but do not remember where it was (yes, you _could_ <code class="literal">git grep bundle t/</code>, but that does not illustrate the point!):</p><div class="literallayout"><p>$ git log --no-merges t/</p></div><p>In the pager (<code class="literal">less</code>), just search for "bundle", go a few lines back, and see that it is in commit 18449ab0… Now just copy this object name, 